As computerized systems have increased in popularity, so have the needs to distribute files and processing resources of computer systems in networks both large and small. In general, computer systems and related devices communicate information over a network for a variety of reasons, for example, to exchange personal electronic messages, sell merchandise, provide account information, and so on and so forth. One will appreciate, however, that as computer systems and their related applications have become increasingly more sophisticated, the challenges associated with sharing data and resources on a network have also increased.
Some current ways for distributing resources within an organizational network might involve a centralized server or computing system (or local device) sharing resources with one or more clients (or remote devices) that may or may not have such resources installed locally. Such systems normally use a dedicated protocol such as Remote Desktop Protocol (“RDP”), Independent Computing Architecture (ICA), and others, to share various applications with such remote clients. With such protocols, a client computer system can access a centralized network server or computing system, which hosts resources of interest and interact (e.g., sending mouse and keyboard events, etc.) with those resources just as though those resources were installed locally.
The network server in turn processes those interactions, creates corresponding rendering information of the data, and sends both the processed data and created rendering information back to the client. The client computer system then receives the data and rendering information, and uses a client-side video driver to render and display the received data locally. Ideally, this interaction between the client computer system and network system occurs seamlessly as though the client computer had actually processed the data locally with its own installed resources.
Another type of real-time system that is similar in most respects to the centralized sharing model described above involves broadcasting of graphics data for application (e.g., a desktop) screen sharing. This type of feature is also sometimes referred to as a remote assistance program. In this example, the broadcasting computer (e.g., an instructor in a learning environment) and the recipient computer systems (e.g., students) connect using a commonly-installed application program that allows for sharing of desktop views and locally installed applications at the instructor computer. Similar to the centralized computing system scenario, the client computer systems (i.e., the students) might be able to interact with the windows displayed at the instructor's computer as though the windows were the viewer's own computer.
One difference between a single client scenario described above and the screen sharing/remote assistance programs, however, is there are typically multiple users involved in the later. One of the users is typically referred to as a “sharer” that shares the content of his/her computer desktop or other application; the other user's are known as “viewers” that use the remote client to view the content broadcasted by the sharer. In such cases, these multiple users (i.e., the sharer and viewers) typically share the control of the sharer's desktop based on certain restrictions that may be set by the sharer.
The protocols used in the above remote sessions utilize bitmaps for sharing at least portions of application user interfaces, which are sent across a graphics stream for viewing on the remote device. Because bitmaps are expensive in terms of bandwidth consumption when transmitted over a network connection (e.g., the Internet), rather than sending the entire bitmaps most systems nowadays (such as those described above) send graphic primitives and/or other orders, which tell a sub-routine on the client side what and how to draw something. For example, a client may be told to draw a rectangle, line, circle, etc. along with information about where it should be drawn, what size, color, etc. For instance, a rectangle may be used to draw a button for a user interface, a border around a document, or any other purpose for which a rectangular shape may be useful. Of course, there are many other shapes and operations that can be used as primitives, delta, and/or other types of encoding (e.g., compression mechanisms) that may be more sophisticated and require more processing that must be done to transfer and perform the operation on the remote client.
In most application sharing scenarios, protocols require state to be maintained between the sharer and viewers. This is especially true if the sharer is broadcasting a single stream of data to all viewers, which is typically the case since encoding separate streams for each viewer requires tremendous amounts of processing and memory resources on the sharer. Accordingly, in such single stream broadcasts scenarios, when a viewer joins the graphics stream, a stream reset is usually necessary that changes the encoding of the graphics stream. The reason for this is simple. A new viewer that joins the stream will not have its state in sync with the state of the sharer (and/or other viewers in the remote session); and therefore, it will not be able to act on the data sent by the sharer. For example, during a real-time remote session, viewers can randomly join and disjoin from the session. Note that during such time, however, the sharer is continually sending graphics data and commands in the broadcast stream. Viewers that subsequently join after the broadcast of certain primitives described above will not have sufficient information on their system to act on later orders that manipulate such data. Similarly, systems that use compression techniques such as LZ (Lempel-Ziv) based encoders/decoders require synchronization of compression histories, which also need to be synced when viewers are added.
In other words, delta encoding, bitmap caching, LZ compression, and other techniques are used to encode data based on information that was previously sent to the client. Without this information, a client cannot decode the data. As such, a stream reset is needed whenever a new viewer is added to the remote session, which typically means that the server will not encode any new information based on what was previously sent to the viewers. Instead, the server assumes that there is no such previous information when a newly joined client is added.
A stream reset, however, can be expensive in terms of bandwidth that is used, which translates directly into reduced update rate that degrades the user experience by delays in the broadcast graphics stream. This becomes more and more problematic in broadcasts with a large number of viewers and/or where viewers randomly join and leave the broadcast quite frequently. In cases like this, the user experience can degrade to the point where the viewers cannot even receive the graphic stream.